An FPGA is often used to prototype logic designs for custom silicon devices such as ASICs, and the like. Because an FPGA is less expensive and typically takes less time to develop than an ASIC or similar device, the logic design intended for an ASIC is often ported to an FPGA for evaluation prior to committing it to production. An FPGA may also be included in the design of a final product that does not need the high performance, low cost or design capacity of an ASIC. In this case, the expense associated with developing a custom silicon device is not justified when compared to the cost of using an FPGA with customized logic.
Conventional systems and methods used to develop, emulate and verify an FPGA design, include, inter alia, logic simulators, logic emulators, custom prototype boards, and evaluation boards.
Logic simulators are software programs that analyze and test hardware designs as expressed in Hardware Description Languages (HDLs). Logic simulators provide a means to test interfaces and test sequences to model the expected operation of the design of an FPGA or similar device in its target electrical operating environment. However, logic simulators are slow when compared to the speed of an FPGA. Logic simulators only model the behavior of digital events and are typically not used to model analog behavior of the various components of an FPGA. Logic simulators also cannot model the constraints imposed by the physical structure of a typical FPGA, such as package pin functions, and the like. Logic simulators also provide no information about physical constraints of the FPGA such as its power supply current limitation, pinout restrictions, device logic capacity, and the like.
Logic emulators are used to boost the performance of logic simulators. Logic emulators typically employ special purpose hardware to accelerate simulation speed. The logic emulator is intended to speed up the same types of events that logic simulators model, namely, digital events. Hence, logic emulators provide no new information over logic simulators and cannot determine whether a logic design will fit within a specific FPGA or if the FPGA will operate at the desired speed of the target system.
Custom hardware prototype boards are often used to verify the design of an FPGA before committing it to production. A typical prototype board may include all, or a subset of, the components intended to interact with an FPGA. By definition, prototype boards are considered flawed. The very purpose of building a prototype board is to discover design flaws in hardware and system design of the FPGA. Errors involving the pinout configuration of the FPGA typically cannot be repaired without re-building the entire prototype board. Errors related to the power supplies of the FPGA may result in a non-functional board. Errors in configuration and programming interfaces often result in an FPGA that cannot be programmed on the prototype board. Prototype boards are also very expensive and time consuming to build.
Another approach to prototyping and evaluating an FPGA design employs evaluation boards. Evaluation boards are developed for the purpose of providing a known good hardware implementation of an FPGA on a premanufactured board. The evaluation board typically has all the required support circuits and connections to use an FPGA with the desired design to be prototyped. Evaluation boards may incorporate other electronic components, e.g., memories, communications ports, oscillators, and the like, that are commonly connected to the FPGA in a complex system.
One problem with evaluation boards is that the FPGA design typically has to be modified or tailored to fit on an existing evaluation board. Evaluation boards often have an FPGA device that is close, but not exactly the same as, the desired FPGA device. In other cases, the evaluation board may have the desired FPGA device but it is not mounted in the desired device package. The result is the evaluation board may not provide information about the validity of pinout configurations of the target FPGA design. Because the FPGA on an evaluation board is connected with specific pins connected to specific components, the desired FPGA design must be changed to fit within the connections of the pre-existing evaluation board. This requires the pinout of the target FPGA design to be changed to match the connections on the evaluation board. When the FPGA on the evaluation board is not the same as the desired target FPGA device, the programming image of the FPGA design must be modified to match the evaluation board. The logic in the desired FPGA design may also have to be modified to fit within the available FPGA device and communicate with the connected devices on the evaluation board. Any changes to the target FPGA design have the potential to prevent detection of errors in the design, or may introduce new errors, in the target FPGA design, rendering the modeling effort useless.
Conventional emulation systems and logic simulators also provide no way to emulate and verify the internal operation of the various components within an FPGA in the actual target environment of the FPGA using software. Conventional emulation systems and logic simulators are typically intended to operate decoupled from the target operating environment of the actual FPGA design. Thus, the operation of design components inside the FPGA can only be tested apart from the external components they are intended to communicate with. Conventional emulation systems have some capability to replace the FPGA component in its native operating environment. However, electrical communication with an emulator prohibits high speed communication between the emulated FPGA design and the native environment. Testing of actual FPGA circuits at the speed they are intended to operate in their native operating environment typically cannot be achieved with conventional emulation systems and logic simulators.
Conventional logic simulators and emulation systems often provide inaccurate system models, inaccurate FPGA circuit models, and inaccurate design translation software. Once an FPGA is programmed and operating in its native operating environment, the FPGA interacts with real devices which behave differently than their corresponding models in simulation or emulation. The reactions of components inside the programmed FPGA differ accordingly. Moreover, the circuit elements programmed in the FPGA are translated from their HDL descriptions to circuit elements. In practice, this translation process is imperfect, resulting in differences between design function in simulation or emulation and in the native operating environment of the FPGA device. Furthermore, simulation models of analog and special purpose circuit elements of an FPGA are used to verify operation of custom defined circuits. In practice, these models and the circuits they model are imperfect and functional differences result between logic simulation or emulation and actual FPGA designs.
Conventional logic simulators and emulation systems are often used to model and test the design behavior of various components inside the FPGA, such as memories, microprocessors, SERDES, and the like. In practice, these models are not as accurate as the elements they model in the actual FPGA components. The technology mapping from the original FPGA design description to FPGA components differs from the models used in both logic simulators and conventional emulation systems. This mapping difference results in functional differences between the simulated or emulated designs and the actual FPGA designs.